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Ascend Tunnel Management Protocol - ATMP 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


IESG Note: 


This note documents a private protocol for tunnel management. This 
protocol is NOT the product of an IETF working group nor is it a 
standards track document. There is ongoing effort in an IETF working 
group which could result in a standards track document which 
specifies a protocol which provides similar functionality. 


Abstract 


This document specifies a generic tunnel management protocol that 
allows remote dial-in users to access their home network as if they 
were directly attached to the home network. The user’s client 
software uses an address contained in the home network address space 


for the remote access. Packets to and from the home network are 
tunneled by the Network Access Server (NAS) to which the user 
connects and a Home Agent (HA) on the user’s home network. This 


allows for the support of access to Virtual Private Networks and also 
allows for the use of protocols other than IP to be carried over the 
tunnel. An example of how the RADIUS (Remote Authentication Dial In 
User Service) can be used to provide the necessary configuration 
information to support this service is also provided. 


1. Introduction 


The Ascend Tunnel Management Protocol (ATMP) is a protocol currently 
being used in Ascend Communication products to allow dial-in client 
software to obtain virtual presence on a user’s home network from 
remote locations. A user calls into a remote NAS but, instead of 
using an address belonging to a network directly supported by the 
NAS, the client software uses an address belonging to the user’s 


"Home Network". This address can be either provided by the client 
software or assigned from a pool of addresses from the Home Network 
address space. In either case, this address belongs to the Home 


Network and therefore special routing considerations are required in 
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order to route packets to and from these clients. A tunnel between 
the NAS and a special "Home Agent" (HA) located on the Home Network 
is used to carry data to and from the client. 


ATMP currently allows for both IP and IPX protocols to be tunneled 
between the NAS and the HA. The protocol to be used, the HA to use, 
and other user specific information is provided by some configuration 
mechanism that is beyond the scope of this document. Appendix A 
illustrates how RADIUS [5] is used to convey this information to the 
NAS. 


The determination of the Home Network address to be used can be 
accomplished in different ways. It could, for example, be configured 
in the client and negotiated by IPCP (or IPXCP). Alternatively, it 
could be defined to be an address specific to the given user ID, or 
it could be assigned from a pool of addresses provided by the Home 
Network for the purpose of remote dial-in access. Again, how this 
address is assigned and how the NAS decides to invoke ATMP fora 
specific call is beyond the scope of this document. 


1.1 Protocol Goals and Assumptions 


The ATMP protocol is implemented only by the NAS and HA. No other 
systems need to be aware of ATMP. All other systems communicate in 
the normal manner and are unaware that they may be communicating with 
remote clients. The clients themselves are unaware of ATMP. It is 
assumed that standard PPP [8] (or SLIP) clients are being used. 


Unlike the mobile-IP protocol [3], ATMP assumes that a single NAS 
will provide the physical connection to a remote client for the 
duration of the session. The client will not switch between NASes 
expecting to keep the same IP address and all associated sessions 
active during these transitions. A particular client can be 
registered with a given HA only once at any given time. 
Deregistration with a HA implies loss of all higher layer sessions 
for that client. 


IP multicasting is currently not provided by ATMP. 

1.2 Terminology 
The terminology used in this document is similar to that used in 
mobile-IP. As pointed out in the previous section, however, ATMP 
provides a subset of the functionality provided by mobile-IP and the 


meanings of the various terms used herein have been modified 
accordingly. 
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Connection Profile 


A table used to route packets other than by destination 
address. The Connection Profile is a named entity that 
contains information indicating how packets addressed to it are 
to be routed. It may be used to route packets to unregistered 
IP addresses and for routing protocols other than IP (e.g., 
IPX). 


Foreign Agent (FA) 


A routing entity that resides in a NAS on a remote network that 
allows a mobile node to utilize a home network address. It 
tunnels datagrams to, and detunnels datagrams from, the home 
agent for the given home network. 


Home Address 


An address that is assigned for an extended period of time to a 
mobile node. It may remain unchanged regardless of where the 
MN is attached to the Internet. Alternatively, it could be 
assigned from a pool of addresses. The management of this pool 
is beyond the scope of this document. 


Home Agent (HA) 


A router on a mobile node’s home network which tunnels 
datagrams for delivery to, and detunnels datagrams from, a 
mobile node when it is away from home. 


Home Network 


The address space of the network to which a user logically 
belongs. When a workstation is physically connected to a LAN, 
the LAN address space is the user’s home network. ATMP 
provides for a remote virtual connection to a LAN. 


Mobile Node (MN) 
A host that wishes to use a Home Network address while 
physically connected by a point-to-point link (phone line, 
ISDN, etc.) to a NAS that does not reside on the Home Network. 
Also referred to as the client. 


Mobility Binding 


The association of a Home Address with a Foreign Agent IP 
address and a Tunnel ID. 
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Network Access Server (NAS) 


A device providing temporary, on-demand, network access to 
users. This access is point-to-point using phone or ISDN 
lines. 


Tunnel 


The path followed by a datagram when it is encapsulated. The 
model is that, while it is encapsulated, a datagram is routed 
to a knowledgeable decapsulation agent, which decapsulates the 
datagram and then correctly delivers it to its ultimate 
destination. Each mobile node connecting to a home agent does 
so over a unique tunnel, identified by a tunnel identifier 
which is unique to a given FA-HA pair. A tunnel can carry both 
IP and IPX datagrams simultaneously. 


1.3 Protocol Overview 


A mobile node that wishes to use a home address while connected to a 
remote NAS must register with the appropriate home agent. The 
foreign agent entity of the remote NAS performs this registration on 
behalf of the MN. Once registered, a tunnel is established between 
the FA and HA to carry datagrams to and from the MN. While a MN is 
registered with an HA, the HA must intercept any packets destined for 
the MN’s home address and forward them via the tunnel to the FA. When 
the FA detects that the MN has disconnected from the NAS, it issues a 
deregister request to the HA. 


Because ATMP allows protocols other than IP to be carried on its 
tunnels and also allows unregistered IP address to be used to provide 
for access to enterprise networks, the HA doesn’t necessarily route 
datagrams received from the MN in the conventional manner. The 
registration request allows for a named "Connection Profile" to be 
specified in the registration request. This Connection Profile 
contains configuration information that tells the HA where to send 
packets that it receives from the MN. 


1.4 Specification Language 


In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. 


MUST This word, or the adjective "required", means 


that the definition is an absolute requirement 
of the specification. 
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MUST NOT 


SHOULD 


MAY 


silently discard 
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This phrase means that the definition is an 
absolute prohibition of the specification. 


This word, or the adjective "recommended", 
means that, in some circumstances, valid 
reasons may exist to ignore this item, but 
the full implications must be understood and 
carefully weighed before choosing a different 
course. Unexpected results may result 
otherwise. 


This word, or the adjective "optional", means 
that this item is one of an allowed set of 
alternatives. An implementation which does 
not include this option MUST be prepared to 
interoperate with another implementation which 
does include the option. 


The implementation discards the datagram 
without further processing, and without 
indicating an error to the sender. The 
implementation SHOULD provide the capability of 
logging the error, including the contents of 
the discarded datagram, and SHOULD record the 
event in a statistics counter. 


2.0 Protocol Specification 


ATMP defines a set of request and reply messages sent with UDP [4]. 
The HA listens on UDP port 5150 [6]) for requests from FA's. The UDP 
checksum field MUST be computed and verified. There are 7 different 
ATMP message types represented by the following Type values: 
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Message Type Type code 
Registration Request 1 
Challenge Request 2 
Challenge Reply 3 
Registration Reply 4 
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Deregister Request 5 
Deregister Reply 6 
Error Notification 7 


2.1 Registration Request 


The FA issues a Registration Request to request the HA to establish a 
mobility binding for the specified MN home address. The request is 
issued to the HA by the FA upon detecting a MN that wishes to use a 
home address supported by the HA receiving the request. 


IP fields 
Source Address The IP address of the foreign agent 
interface from which the request is 
issued. 
Destination Address The IP address of the home agent. 
UDP fields: 
Source Port variable 
Destination Port 5150 (or port number configured in FA 


for given HA) 
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The UDP header is followed by the ATMP fields shown below: 


0 1 
0.1.2.3. 4,9: 6 7-8 90 1 


2 3 
2.3. 4°96. 7 8°90. 2 34 S 6 7-8 9 0 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Version | Type | Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Foreign Agent | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Mobile Node | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Mobile Node Mask | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Mobile Node IPX Net | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|Mobile Node IPX Station 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


reserved 


+-4-4+-4-4-4-4-4-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4-4+-4+-4+-4+-4+-4-4+-4-4-4-4-4-4-4 


Home Network Name 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Version 


Type 


Identifier 


Foreign Agent 


Mobile Node 


Mobile Node Mask 


Mobile Node IPX Net 


The ATMP protocol version. MUST be 1. 
1 for Registration Request. 


A 16 bit number used to match replies 
with requests. A new value should be 
provided in each new request. 
Retransmissions of the same request 
should use the same identifier. 


The IP address of the foreign agent 
issuing the request (typically the same 
as the UDP source address). 


The IP address to be used by the mobile 
node. This is the mobile node’s home 
address. This field can be all 0’s if 
IPX is to be tunneled to the mobile node. 


The network bit mask for the mobile node. 
Currently this value should be set to all 
1’s 


The Network portion of the mobile node’s 
IPX address. This value should be set to 
all 0’s if only IP is to be tunneled. 
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Mobile Node IPX Station 


Reserved 


HN Name 


2.2 Challenge Request 
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The 6 octet value used to represent the 
station portion of the mobile node’s IPX 
address. This value should be set to all 
O's if only IP is to be tunneled instead 
of IPX. 


This field is for future extensibility 
and MUST be set to all O's. 


This is the name of the "Connection 
Profile" to be used by the home agent to 
forward all packets received from the 
mobile node. This character string is 
terminated by a NUL character and can be 
up to 32 characters long, including the 
NUL terminator. 


The Home Agent issues a Challenge Request in response to the receipt 
of a Registration Request from a Foreign Agent. It is used by the 
Home Agent, in conjunction with the Challenge Reply, to authenticate 


the Foreign Agent. 
IP fields 


Source Address 


Destination Address 


UDP fields: 
Source Port 


Destination Port 


Hamzeh 


The IP address of the Home Agent 
interface from which the request is 
issued. 


Copied form the Source Address of the 
Registration Request. 


variable 


Copied from the Source Port of the 
Registration Request. 
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The UDP header is followed by the ATMP fields shown below: 


0 1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Version | Type | Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


Authenticator 


tata tata ta tata tata tata tata ta tata tata ta ta tata ta tata ta tata tata ta tat 
| Result Code 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


Version The ATMP protocol version. MUST be 1. 
Type 2 for Challenge Request 
Identifier A 16 bit number used to match replies 


with requests. A new value should be 
provided in each new request. 
Retransmissions of the same request 
should use the same identifier. 


Authenticator A series of 16 octet values randomly 
generated by the Home Agent. The 
receiving Foreign Agent is to perform an 
MD5 [7] hash of these values along with a 
shared secret. The resultant digest is 
returned in the Challenge Reply. See 
Sec. 2.3 Retransmissions of the Challenge 
Request should use the same Authenticator 
value. 


A value of all 0O’s in this field 
indicates an error occurred with the 
Registration Request. The error code 
will be in the following field. 
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Result Code 


2.3 Challenge Reply 
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If non-zero, this value indicates the 
error condition that occurred. See Sec. 
2.8 for a list of Result Code values and 
their meanings. 


A non-zero value in this field implies 
that the Authenticator field will be 
zero. 


The Foreign Agent issues a Challenge Reply upon receipt of a valid 
Challenge Request (one with a Result Code of 0) from the Home Agent. 
The Foreign Agent uses the randomly generated Authenticator value 
from the Challenge Request along with a shared secret to produce an 
MD5 digest value which is returned to the Home Agent in the Challenge 


Reply. 
IP fields 


Source Address 


Destination Address 


UDP fields: 
Source Port 


Destination Port 


The IP address of the Foreign Agent 
interface from which the reply is issued. 


Copied from the Source Address of the 
Challenge Request. 


variable 


Copied from the Source Port of the 
Challenge Request. 


The UDP header is followed by the ATMP fields shown below: 


0 


2 3 


012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Version | 


| Identifier | 


+-4+-4-4-4-4-4-4-4-4-4+-4+-4-4+-4+-4+-4-4+-4-4+-4-4-4-4-4-4+-4-4-4-4-4-4-4 


| Reply Length 


| Reply 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Version The ATMP protocol version. MUST be 1. 
Type 3 for Challenge Reply 
Identifier Copied from the corresponding 


Deregistration Request. 


Reply Length This field specifies the length of the 
challenge reply computation based on the 
received Authenticator and the shared 
secret. For MD5 this length will always 
be 16. This field is provided for future 
extensibility. 


Reply This is the computed challenge reply. It 
is computed by performing an MD5 message 
digest computation over the Authenticator 
value received in the Challenge Request 
appended with the secret shared between 
the Foreign Agent and the Home Agent. 

The digests produced by MD5 are always 16 
octets long. 


2.4 Registration Reply 


A Registration Reply is issued by a Home Agent in reply toa 
Challenge Reply received from a Foreign Agent. The Registration 
Reply indicates to the Foreign Agent whether the registration was 
accepted by the Home Agent or not. It also provides a "tunnel ID" to 
uniquely identify the tunnel to be associated with this session. 


The Home Agent calculates the same MD5 hash on the Challenge Request 
Authenticator field and the shared secret. The resulting digest is 
compared with the Reply value in the Challenge Reply and if it is 
equal, authentication is successful. Otherwise the registration is 
not accepted and the Foreign Agent is informed by the Result Code of 
the Registration Reply that registration failed due to an 
authentication failure. 


IP fields 
Source Address The IP address of the Home Agent 
interface from which the reply is issued. 
Destination Address Copied from the Source Address of the 


Challenge Reply. 
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Source Port 


Destination Port 
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variable 


Copied from the Source Port of the 
Challenge Reply. 


The UDP header is followed by the ATMP fields shown below: 


0 


2 3 


OT 22°34 OPO TB Oo OT 233496 EB Ga Or L 2 BAe b T2859." Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Version 


| Identifier | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Result Code 


| Tunnel ID | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Version 


Type 


Identifier 


Result Code 


Tunnel ID 


Hamzeh 


The ATMP protocol version. MUST be 1. 
4 for Registration Reply 


Copied from the corresponding 
Registration Request. 


Specifies the result of the registration 
and authentication attempt by the Foreign 
Agent. Sec. 2.8 for a list of Result 
Code values and their meanings. 


This is the identifier used to indicate a 
given mobility binding between a given 
Mobile Node and Home Agent. This 
identifier is used to distinguish 
multiple tunnels between a given Foreign 
Agent-Home Agent pair. It is carried in 
the "key" field of the GRE [1] tunnel 
packets that ATMP uses as the tunnel 
protocol. It is also used in 
Deregistration Requests and Error 
Notification messages to indicate the 
particular mobility binding to which they 
relate. 
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2.5 Deregistration Request 


The Deregistration Request is issued by the Foreign Agent to the Home 
Agent to indicate that the specified mobility binding is to be ended. 
This request may result from the Foreign Agent detecting that its 
connection to the Mobile Node has terminated. It can also be issued 
in response to a detected error condition by the Foreign Agent or 
receipt of an Error Notification message from the Home Agent. 


IP fields 
Source Address The IP address of the Foreign Agent 
interface from which the request is 
issued. 
Destination Address 5150 (or port number configured in FA 
for given HA) 
UDP fields: 
Source Port variable 
Destination Port Copied from the Source Port of the 


Challenge Reply. 


The UDP header is followed by the ATMP fields shown below: 


0 1 2 3 
O12 3°45 67.8 9 0 12.3°4.-5°6 78690 12345 67-8 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Version | Type | Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Tunnel ID | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Version The ATMP protocol version. MUST be 1. 
Type 5 for Deregistration Request 
Identifier A 16 bit number used to match replies 


with requests. A new value should be 
provided in each new request. 
Retransmissions of the same request 
should use the same identifier. 
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Tunnel ID Tunnel identifier of the mobility binding 
to be terminated. 


2.6 Deregistration Reply 


The Deregistration Reply is issued by the Home Agent in response to a 
Deregistration Request received from a Foreign Agent. If the 
Deregistration Request was valid, the Home Agent removes the 
specified mobility binding from its tables and issues an affirmative 
reply. Otherwise the Home Agent issues a Deregistration Reply with a 
Result Code indicating the reason for failure of the Deregistration 


Request. 
IP fields 
Source Address The IP address of the Home Agent 
interface from which the reply is issued. 
Destination Address Copied from the Source Address of the 
received Deregistration Request. 
UDP fields: 
Source Port variable 
Destination Port Copied from the Source Port of the 


received Deregistration Request. 
The UDP header is followed by the ATMP fields shown below: 
0 1 2 3 


O123 45 67°83 90123456783 90 123.45 6 7 8 9-0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 


| Version | Type | Identifier 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Result Code | Tunnel ID 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Version The ATMP protocol version. MUST be 1. 
Type 6 for Deregistration Reply 
Identifier Copied from the corresponding 


Deregistration Request. 
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Result Code 


Tunnel ID 


2.7 Error Notification 


ATMP February 1997 


Specifies the result of the registration 
and authentication attempt by the Foreign 
Agent. Sec. 2.8 for a list of Result 
Code values and their meanings. 


Tunnel identifier of the mobility binding 
specified in the Deregistration Request. 


This message is sent by either agent to inform the other agent that 
an error condition has occurred. It provides a last-ditch error 
recovery mechanism that is used for conditions that cannot be 
reported back to the sender by the normal request-reply mechanism, 
such as the receipt of a spontaneously generated reply. 


IP fields 


Source Address 


Destination Address 


UDP fields: 


Source Port 


Destination Port 


The IP address of the issuing agent 
interface from which this message is 
issued. 


The IP address of the Home Agent or 
Foreign Agent to which this message is to 
be issued. 


variable 


If issued to a Home Agent, 5150 (or the 
port number configured for the given HA). 
If issued to a Foreign Agent, the source 
port number saved from the original 
Registration Request. 


The UDP header is followed by the ATMP fields shown below: 


0 


2 3 


0.1.2.3. 4,.9 6 7-8 9 0 .1-2-3.°4-°5°6 7 8 90, EL 2 34° 6. 7-8 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Version | 


| Identifier | 


+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4+-4+-4-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4 


| Result Code 


| Tunnel ID | 


+-4+-4-4-4-4-4-4-4-4+-4+-4-4-4+-4+-4+-4+-4+-4+-4-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4 
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Version 


Type 


Identifier 


Result Code 


Tunnel ID 


2.8 Result Codes 


0 


Error Code 


NO_ERROR 


AUTH_FAILED 


NOT_ENABLED 


TOO_MANY 


PARAMETER_ERROR 


INVALID_TUNNEL_ID 


TIMEOUT 
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The ATMP protocol version. MUST be 1. 
7 for Error Notification 


If issued in response to a received reply 
type message, this value should be copied 
from the identifier field of the reply. 
Otherwise the identifier should be the 
value that would be used for the next 
generated request. 


This indicates the type of error 
detected. The possible result codes are 
defined in Sec. 2.8. 


Tunnel identifier of the mobility binding 
to which this message pertains. If the 
Error Notification is being sent in 


response to an unsolicited reply, the 
Tunnel ID is copied from the reply. 


Description 
Successful operation 


Authentication of the Foreign Agent failed. 
Registration denied. 


The Home Agent is not configured to run ATMP. 


Too many Mobile Node sessions. Home Agent is out 
of resources. 


An invalid value was detected in an ATMP message. 
The Tunnel ID contained in a GRE packet is 
invalid or the corresponding mobility binding 
does not exist. This usually occurs when either 


the MN or HA has reset. 


A response to an ATMP request was not received in 
time. 
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7 NET_UNREACHABLE The Home Network for this mobility binding is not 
operational (the "Connection Profile" is "down" 
or is not defined). 


8 GENERAL ERROR General Error indication. 
2.9 Protocol Operation 


Upon detection of a Mobile Node requiring ATMP service, the NAS 
invokes its ATMP Foreign Agent entity.The FA retrieves configuration 
information for the user involved.This information is obtained ina 
method particular to the NAS and is not specified by this document. 
The information obtained MUST include the Home Agent address and the 
shared secret for this HA.It also MAY include the Home Network Name, 
if a Connection Profile is to be used for this session. 


The FA then sends a Registration Request to the HA informing it that 
an MN wishes to register with it. The FA then waits for the HA to 
respond with a Challenge Request. The FA retransmits the 
Registration Request every 2 seconds until it receives the Challenge 
Request. If, after 10 retransmissions, no Challenge Request is 
received, the FA will terminate the Registration Request, logs the 
registration failure, and disconnects the MN. 


Upon receipt of the Challenge Request, the FA examines the Result 
code. If it indicates an error condition, the condition is logged 
and the MN is disconnected. If the result is zero, the FA generates 
a Challenge Reply. The Challenge Reply is generated by appending the 
Authenticator obtained from the Challenge Request with the shared 
secret (obtained from the configuration data) and then computing the 


MD5 hash of this concatenated string (authenticator + secret). The 
16 octet hash is then returned in the Challenge Reply for validation 
by the HA. 


Upon receipt of the Challenge Reply from the FA, the HA does the same 
computation of the MD5 hash based on the Challenge Request 
Authenticator and the shared-secret (which it too must be configured 
with). If this digest matches that provided in the Challenge Reply 
by the FA then the authentication is successful and the registration 
is accepted. If the authentication fails, or resource limitations 
prohibit the registration attempt, the HA returns a Registration 
Reply with a non-zero result code to the FA. 


If the HA accepts the Challenge Reply from the FA, it assigns a 
Tunnel ID to this session and returns this Tunnel ID ina 
Registration Reply with a zero result code. This Tunnel ID needs to 
be unique for the FA-HA pair. The Tunnel ID is used to multiplex and 
demultiplex the packets sent between a given FA-HA pair. 
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At the time the HA decides to accept a registration, it creates a 
control block that associates the Tunnel ID with the appropriate 
routing information. If the Registration Request included a Home 
Network Name, this name is saved in the table and used as the name of 
the Connection Profile for this session. 


Upon receipt of the Registration Reply, the FA examines the result 
code. If it is non-zero, the FA logs the registration failure and 
disconnects the MN. If it is zero, the FA saves the Tunnel ID ina 
control block associated with the MN session. The FA and HA are now 
ready to exchange data packets for this MN session. 


On the FA side, all data received from the MN will be encapsulated 
using GRE and sent to the HA with the assigned Tunnel ID included in 
the GRE Key field. When the HA receives a GRE packet it decapsulates 
it and routes it using the routing information contained in the HA’s 
control block associated with this Tunnel ID. 


When the HA receives a packet destined for the MN’s Home Address, it 
MUST encapsulate it in a GRE packet and forward it to the appropriate 
FA. The Tunnel ID is included in the GRE Key field to allow the FA 
to demultiplex the packet. 


When the FA receives a GRE packet, it will examine the Tunnel ID in 
the GRE Key field to see if it matches the Tunnel ID assigned to any 
of the MN’s currently connected to the FA. If so, the packet is 
decapsulated and forwarded to the MN. If the Tunnel ID doesn’t match 
any active MN’s, an Error Notification message is issued to the HA 
and the GRE packet is silently discarded. 


When the FA wishes to disconnect the MN from the HA, it issues a 
Deregistration Request. This request is issued every 2 seconds. If 
after 10 attempts a Deregistration Reply is not received from the HA, 
an error condition is logged and the MN is disconnected. Upon 
receipt of a Deregistration Reply from the HA, the FA deallocates the 
Tunnel ID and disconnects the MN. 


3.0 Security Considerations 


The Registration function of ATMP is protected by a 
Challenge/Response mechanism similar to CHAP [2]. The Home Agent 
challenges each registration attempt by a Foreign Agent for 
authentication.This authentication requires the configuration of a 
shared secret for each HA/client pair. 
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Appendix A 
Additional RADIUS Attributes for ATMP 
This appendix indicates the RADIUS attributes that have been added by 


Ascend to support ATMP for IP. Currently these are defined as non- 
vendor-specific attributes but have been included in [5]. 


Attribute: "Ascend-Home-Agent—-IP-Addr" 

Type: IP-Address 

Value: The IP address of the Home Agent 

Attribute: "Ascend-Home-Agent-Password" 

Type: String 

Value: Secret shared for this user with HA 

Attribute: "Ascend-Home-Network-Name" 

Type: String 

Value: Name of Connection Profile for this session 

Attribute: "Ascend-Home-Agent-UDP-Port" 

Type: Integer 

Value: The destination UDP port number for the specified HA 
Appendix B 


IPX Operation 


ATMP specifies a mechanism which allows IPX clients to receive 
mobility services from a HA. Section 2 details the protocol used 
to register, deregister, and authenticate a tunnel used for IPX. 
Note that ATMP is based on IP datagrams for the management of 
tunnels and, thus, IPX tunneling with ATMP always requires an 
underlying IP network. 


Each IPX mobile client requires an IPX network number and node 
address pair. Since IPX does not support a similar facility to 
IP’s "host route," an enterprise-unique network number needs to be 
chosen for each home agent. This network number MUST be distinct 
from the IPX network number assigned to any of the home agent’s 
LAN interfaces. Each mobile client tunneled to the home agent MUST 
use the same IPX network number. 


For example, consider a home agent which supports two mobile 


clients. The home agent is on a LAN network with an IPX address 
of AA000001. The home agent’s client network may be assigned 
AA000002. The two mobile clients may have addresses 


AA000002:0040F1000001 and AA000002:0040F1000002 respectively. 
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IPX node numbers need to be unique on a given network. A mechanism 
must exist to guarantee that for each home agent’s network, a 
given mobile client’s node address is unique. Several techniques 
may be employed to assure unique node addresses. The current 
implementation of ATMP described in this document relies on RADIUS 
to assign a node address at the foreign agent. The following 
RADIUS attributes are included for IPX operation in addition to 
the attributes described in Appendix A for IP operation: 


Attribute: "Framed-IPX-Network" (See [5] for details). 


Attribute: "Ascend-IPX-Node-Addr" 

Type: String 

String: The node address for the mobile client in 12 octet 
ASCII representing the hexadecimal string. Both 
lower and upper case characters are permissible. 
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